Technologies for network packet processing between cloud and telecommunications networks

ABSTRACT

Technologies for network packet processing between cloud and telecommunications networks includes a network computing device which includes two application layer packet translators (ALPTs). The first ALPT is configured to receive a network packet from a computing device in a telecommunications network, identify a virtual network function (VNF) instance, and perform an application layer encapsulation of at least a portion of data of the received network packet as a parameter of a remote procedure call (RPC) associated with the identified VNF instance. The first ALPT is additionally configured to invoke the identified VNF instance using an API call corresponding to the RPC that includes the RPC parameter and the VNF instance is configured to transmit an RPC call response to the second ALPT. The second ALPT is configured to generate a new network packet as a function of the RPC call response and transmit the new network packet to another computing device in a cloud network.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 15/942,012, filed Mar. 30, 2018. The entire specifications ofwhich is hereby incorporated herein by reference in its entirety.

BACKGROUND

Network operators and telecommunication service providers typically relyon various network virtualization technologies to manage complex,large-scale computing environments, such as high-performance computing(HPC) and cloud computing environments. For example, network operatorsand service provider networks may rely on network functionvirtualization (NFV) deployments to deploy network services (e.g.,firewall services, network address translation (NAT) services,load-balancing services, deep packet inspection (DPI) services,transmission control protocol (TCP) optimization services, etc.). SuchNFV deployments typically use an NFV infrastructure to orchestratevarious virtual machines (VMs) to perform virtualized network services,commonly referred to as virtualized network functions (VNF instances),on network traffic and to manage the network traffic across the variousVMs.

Unlike traditional, non-virtualized deployments, virtualized deploymentsdecouple network functions from underlying hardware, which results innetwork functions and services that are highly dynamic and generallycapable of being executed on off-the-shelf servers with general purposeprocessors. As such, the VNF instances can be scaled-in/out as necessarybased on particular functions or network services to be performed on thenetwork traffic. However, effectively deploying and executing the VNFinstances requires vendors to ensure they can achieve packet line rate(e.g., end to end across sequences of VNF instances andforwarders/routers) and work with various variations of network hardwareinterfaces, which requires supporting multiple network protocols,deployment topologies, and configurations. Meeting such requirements canoften lead to increased production costs and hinder efficient, modulardevelopment of VNF instances.

BRIEF DESCRIPTION OF THE DRAWINGS

The concepts described herein are illustrated by way of example and notby way of limitation in the accompanying figures. For simplicity andclarity of illustration, elements illustrated in the figures are notnecessarily drawn to scale. Where considered appropriate, referencelabels have been repeated among the figures to indicate corresponding oranalogous elements.

FIG. 1 is a simplified block diagram of at least one embodiment of asystem for network packet processing between cloud andtelecommunications networks that includes a endpoint computing deviceand a network computing device;

FIG. 2 is a simplified block diagram of at least one embodiment of thenetwork computing device of the system of FIG. 1;

FIG. 3 is a simplified block diagram of at least one embodiment of anenvironment of the network computing device of the system of FIG. 1;

FIGS. 4A and 4B are a simplified flow diagram of at least one embodimentof a method for processing a network packet between cloud andtelecommunications networks that may be executed by the networkcomputing device of FIGS. 1-3;

FIG. 5 is a simplified block diagram of at least one embodiment of anenvironment for running VNF instances implemented as microservices onthe network computing device of FIGS. 1-3; and

FIG. 6 is a simplified block diagram of at least one other embodiment ofa system for network packet processing between cloud andtelecommunication networks that includes the network computing device ofFIGS. 1-3 and 5 illustratively coupled to a virtual network function(VNF) services network of application programming interface (API)/remoteprocedure call (RPC) based microservices.

DETAILED DESCRIPTION OF THE DRAWINGS

While the concepts of the present disclosure are susceptible to variousmodifications and alternative forms, specific embodiments thereof havebeen shown by way of example in the drawings and will be describedherein in detail. It should be understood, however, that there is nointent to limit the concepts of the present disclosure to the particularforms disclosed, but on the contrary, the intention is to cover allmodifications, equivalents, and alternatives consistent with the presentdisclosure and the appended claims.

References in the specification to “one embodiment,” “an embodiment,”“an illustrative embodiment,” etc., indicate that the embodimentdescribed may include a particular feature, structure, orcharacteristic, but every embodiment may or may not necessarily includethat particular feature, structure, or characteristic. Moreover, suchphrases are not necessarily referring to the same embodiment. Further,when a particular feature, structure, or characteristic is described inconnection with an embodiment, it is submitted that it is within theknowledge of one skilled in the art to effect such feature, structure,or characteristic in connection with other embodiments whether or notexplicitly described. Additionally, it should be appreciated that itemsincluded in a list in the form of “at least one of A, B, and C” can mean(A); (B); (C): (A and B); (A and C); (B and C); or (A, B, and C).Similarly, items listed in the form of “at least one of A, B, or C” canmean (A); (B); (C): (A and B); (A and C); (B and C); or (A, B, and C).

The disclosed embodiments may be implemented, in some cases, inhardware, firmware, software, or any combination thereof. The disclosedembodiments may also be implemented as instructions carried by or storedon one or more transitory or non-transitory machine-readable (e.g.,computer-readable) storage media, which may be read and executed by oneor more processors. A machine-readable storage medium may be embodied asany storage device, mechanism, or other physical structure for storingor transmitting information in a form readable by a machine (e.g., avolatile or non-volatile memory, a media disc, or other media device).

In the drawings, some structural or method features may be shown inspecific arrangements and/or orderings. However, it should beappreciated that such specific arrangements and/or orderings may not berequired. Rather, in some embodiments, such features may be arranged ina different manner and/or order than shown in the illustrative figures.Additionally, the inclusion of a structural or method feature in aparticular figure is not meant to imply that such feature is required inall embodiments and, in some embodiments, may not be included or may becombined with other features.

Referring now to FIG. 1, in an illustrative embodiment, a system 100 fornetwork packet processing between cloud and telecommunications networksincludes an endpoint computing device 102 communicatively coupled to anetwork computing device 106 via a telecommunications network 104. Whileillustratively shown as having a single endpoint computing device 102and a single network computing device 106, the system 100 may includemultiple endpoint computing devices 102 and multiple network computingdevices 106, in other embodiments. The illustrative system 100additionally includes a cloud network 108 communicatively coupling thenetwork computing device 106 to a cloud compute/storage device 110(e.g., of a cloud service provider). In use, the endpoint computingdevice 102, or more particularly an application being executed thereon,transmits network packets to the network computing device 106 via thetelecommunications network 104. It should be appreciated that at least aportion of the transmitted network packets include data on which one ormore virtualized services (e.g., firewall services, network addresstranslation (NAT) services, load-balancing services, deep packetinspection (DPI) services, transmission control protocol (TCP)optimization services, etc.) are to be performed on at least a portionof the network packet.

Upon receiving the network packet, the network computing device 106, ormore particularly an application layer packet translator (see, e.g., theapplication layer packet translator of FIG. 3) of the network computingdevice 106, reads and classifies the received network packet based on aflow type of the network packet, such as may be determined as a functionof at least a portion of the data contained in the header and/or payloadof the network packet. The application layer packet translator furtherdetermines a service policy, such as may be defined in a flow database,based on the flow classification which identifies one or more virtualnetwork function (VNF) instances that are to be invoked for the receivednetwork packet. Additionally, the application layer packet translator isconfigured to map the network packet to the one or more VNF instances(e.g., in a network function forwarding table). To call a VNF instance,the application layer packet translator is configured to initiate aremote procedure call (RPC) application programming interface (API) callusing the applicable URI for that VNF instance. It should be appreciatedthat, while the network functions described are described herein asvirtual (i.e., VNF instances), at least a portion of the networkfunctions described herein may not be virtualized, in some embodiments.

When a VNF instance has completed the intended service workload, the VNFinstance calls the application layer packet translator with anindication that the network packet can be processed (e.g., using aprocess packet call). Once the application layer packet translatorreceives a call to process the network packet (i.e., the process packetcall), the application layer packet translator is configured to map theRPC data source associated with the process packet call to specific dataof the received packet, which is to be added/modified in a header of thenetwork packet. It should be appreciated that some VNF instances mayperform some level of processing on at least a portion of the networkpacket data. Accordingly, such VNF instances may call the applicationlayer packet translator with the callback as described above, or returna response with processed packet data to the application layer packettranslator.

Additionally, the application layer packet translator is configured tocreate another network packet as a function of the headeradditions/modifications and applicable data (e.g., payload), and sendthe network packet across the cloud network (e.g., to a compute/storagedevice in a cloud) or to a network computing device 106 of anothertelecommunications provider (e.g., via another telecommunicationsnetwork). It should be appreciated that, in some embodiments, theapplication layer packet translator may be embodied as a VNF instanceitself.

returning a response with processed packet data

The network computing device 106 may be embodied as any type ofcomputation or computer device capable of performing the functionsdescribed herein, including, without limitation, a server (e.g.,stand-alone, rack-mounted, blade, etc.), a sled (e.g., a compute sled,an accelerator sled, a storage sled, a memory sled, etc.), an enhancednetwork interface controller (NIC) (e.g., a host fabric interface(HFI)), a network appliance (e.g., physical or virtual), a router,switch (e.g., a disaggregated switch, a rack-mounted switch, astandalone switch, a fully managed switch, a partially managed switch, afull-duplex switch, and/or a half-duplex communication mode enabledswitch), a gateway, a web appliance, a distributed computing system, aprocessor-based system, and/or a multiprocessor system. Referring now toFIG. 2, the illustrative network computing device 106 includes a computeengine 200, an I/O subsystem 206, one or more data storage devices 208,communication circuitry 210, and, in some embodiments, one or moreperipheral devices 214. It should be appreciated that the networkcomputing device 106 may include other or additional components, such asthose commonly found in a typical computing device (e.g., variousinput/output devices and/or other components), in other embodiments.Additionally, in some embodiments, one or more of the illustrativecomponents may be incorporated in, or otherwise form a portion of,another component.

The compute engine 200 may be embodied as any type of device orcollection of devices capable of performing the various computefunctions as described herein. In some embodiments, the compute engine200 may be embodied as a single device, such as an integrated circuit,an embedded system, a field-programmable-array (FPGA), asystem-on-a-chip (SOC), an application specific integrated circuit(ASIC), reconfigurable hardware or hardware circuitry, or otherspecialized hardware to facilitate performance of the functionsdescribed herein. Additionally, in some embodiments, the compute engine200 may include, or may be embodied as, one or more processors 202(i.e., one or more central processing units (CPUs)) and memory 204.

The processor(s) 202 may be embodied as any type of processor capable ofperforming the functions described herein. For example, the processor(s)202 may be embodied as one or more single-core processors, one or moremulti-core processors, a digital signal processor, a microcontroller, orother processor or processing/controlling circuit(s). In someembodiments, the processor(s) 202 may be embodied as, include, orotherwise be coupled to a field programmable gate array (FPGA), anapplication specific integrated circuit (ASIC), reconfigurable hardwareor hardware circuitry, or other specialized hardware to facilitateperformance of the functions described herein.

The memory 204 may be embodied as any type of volatile (e.g., dynamicrandom access memory (DRAM), etc.) or non-volatile memory or datastorage capable of performing the functions described herein. It shouldbe appreciated that the memory 204 may include main memory (i.e., aprimary memory) and/or cache memory (i.e., memory that can be accessedmore quickly than the main memory). Volatile memory may be a storagemedium that requires power to maintain the state of data stored by themedium. Non-limiting examples of volatile memory may include varioustypes of random access memory (RAM), such as dynamic random accessmemory (DRAM) or static random access memory (SRAM).

The compute engine 200 is communicatively coupled to other components ofthe network computing device 106 via the I/O subsystem 206, which may beembodied as circuitry and/or components to facilitate input/outputoperations with the processor 202, the memory 204, and other componentsof the network computing device 106. For example, the I/O subsystem 206may be embodied as, or otherwise include, memory controller hubs,input/output control hubs, integrated sensor hubs, firmware devices,communication links (e.g., point-to-point links, bus links, wires,cables, light guides, printed circuit board traces, etc.), and/or othercomponents and subsystems to facilitate the input/output operations. Insome embodiments, the I/O subsystem 206 may form a portion of asystem-on-a-chip (SoC) and be incorporated, along with the computeengine 200 (e.g., the processor 202, the memory 204, etc.) and/or othercomponents of the network computing device 106, on a single integratedcircuit chip.

The one or more data storage devices 208 may be embodied as any type ofstorage device(s) configured for short-term or long-term storage ofdata, such as, for example, memory devices and circuits, memory cards,hard disk drives, solid-state drives, or other data storage devices.Each data storage device 208 may include a system partition that storesdata and firmware code for the data storage device 208. Each datastorage device 208 may also include an operating system partition thatstores data files and executables for an operating system.

The communication circuitry 210 may be embodied as any communicationcircuit, device, or collection thereof, capable of enablingcommunications between the network computing device 106 and othercomputing devices, such as the endpoint computing device 102, as well asany network communication enabling devices, such as a gateway, an accesspoint, network switch/router, etc., to allow communication over thetelecommunications network 104. Accordingly, the communication circuitry210 may be configured to use any one or more communication technologies(e.g., wireless or wired communication technologies) and associatedprotocols (e.g., Ethernet, Bluetooth®, Wi-Fi®, WiMAX, LTE, 5G, etc.) toeffect such communication.

It should be appreciated that, in some embodiments, the communicationcircuitry 210 may include specialized circuitry, hardware, orcombination thereof to perform pipeline logic (e.g., hardwarealgorithms) for performing the functions described herein, includingapplying the hash functions, processing network packets (e.g., parsereceived network packets, determine destination computing devices foreach received network packets, forward the network packets to aparticular buffer queue of a respective host buffer of the networkcomputing device 106, etc.), performing computational functions, etc.

In some embodiments, performance of one or more of the functions ofcommunication circuitry 210 as described herein may be performed byspecialized circuitry, hardware, or combination thereof of thecommunication circuitry 210, which may be embodied as a system-on-a-chip(SoC) or otherwise form a portion of a SoC of the network computingdevice 106 (e.g., incorporated on a single integrated circuit chip alongwith a processor 202, the memory 204, and/or other components of thenetwork computing device 106). Alternatively, in some embodiments, thespecialized circuitry, hardware, or combination thereof may be embodiedas one or more discrete processing units of the network computing device106, each of which may be capable of performing one or more of thefunctions described herein.

The illustrative communication circuitry 210 includes a NIC 212, whichmay also be referred to as an HFI in some embodiments (e.g.,high-performance computing (HPC) environments). The NIC 212 may beembodied as one or more add-in-boards, daughtercards, network interfacecards, controller chips, chipsets, or other devices that may be used bythe network computing device 106 to connect with another compute device(e.g., the endpoint computing device 102). In some embodiments, the NIC212 may be embodied as part of a system-on-a-chip (SoC) that includesone or more processors, or included on a multichip package that alsocontains one or more processors. In some embodiments, the NIC 212 mayinclude a local processor (not shown) and/or a local memory (not shown)that are both local to the NIC 212. In such embodiments, the localprocessor of the NIC 212 may be capable of performing one or more of thefunctions of a processor 202 described herein. Additionally oralternatively, in such embodiments, the local memory of the NIC 212 maybe integrated into one or more components of the network computingdevice 106 at the board level, socket level, chip level, and/or otherlevels.

The one or more peripheral devices 214 may include any type of devicethat is usable to input information into the network computing device106 and/or receive information from the network computing device 106.The peripheral devices 214 may be embodied as any auxiliary deviceusable to input information into the network computing device 106, suchas a keyboard, a mouse, a microphone, a barcode reader, an imagescanner, etc., or output information from the network computing device106, such as a display, a speaker, graphics circuitry, a printer, aprojector, etc. It should be appreciated that, in some embodiments, oneor more of the peripheral devices 214 may function as both an inputdevice and an output device (e.g., a touchscreen display, a digitizer ontop of a display screen, etc.). It should be further appreciated thatthe types of peripheral devices 214 connected to the network computingdevice 106 may depend on, for example, the type and/or intended use ofthe network computing device 106. Additionally or alternatively, in someembodiments, the peripheral devices 214 may include one or more ports,such as a USB port, for example, for connecting external peripheraldevices to the network computing device 106.

Referring back to FIG. 1, the endpoint computing device 102 may beembodied as any type of computation or computer device capable ofperforming the functions described herein, including, withoutlimitation, a mobile computing device (e.g., a smartphone, a tabletcomputer, a laptop computer, a notebook computer, a wearable, etc.), adesktop computer, a server (e.g., stand-alone, rack-mounted, blade,etc.), a sled (e.g., a compute sled, an accelerator sled, a storagesled, a memory sled, etc.), a network appliance (e.g., physical orvirtual), a web appliance, a distributed computing system, aprocessor-based system, and/or a multiprocessor system. While notillustratively shown, it should be appreciated that the endpointcomputing device 102 includes similar and/or like components to those ofthe illustrative network computing device 106. As such, figures anddescriptions of the like components are not repeated herein for clarityof the description with the understanding that the description of thecorresponding components provided above in regard to the networkcomputing device 106 applies equally to the corresponding components ofthe endpoint computing device 102.

Similar to the network computing device 106, the cloud compute/storagedevice 110 may be embodied as any type of computation or computer devicecapable of performing the functions described herein, including, withoutlimitation, a server (e.g., stand-alone, rack-mounted, blade, etc.), asled (e.g., a compute sled, an accelerator sled, a storage sled, amemory sled, etc.), an enhanced NIC (e.g., an HFI)), a network appliance(e.g., physical or virtual), a router, switch (e.g., a disaggregatedswitch, a rack-mounted switch, a standalone switch, a fully managedswitch, a partially managed switch, a full-duplex switch, and/or ahalf-duplex communication mode enabled switch), a web appliance, adistributed computing system, a processor-based system, and/or amultiprocessor system. While not illustratively shown, it should beappreciated that the cloud compute/storage device 110 includes similarand/or like components to those of the illustrative network computingdevice 106. As such, figures and descriptions of the like components arenot repeated herein for clarity of the description with theunderstanding that the description of the corresponding componentsprovided above in regard to the network computing device 106 appliesequally to the corresponding components of the cloud compute/storagedevice 110.

The telecommunications network 104 may be embodied as any type of wiredor wireless communication network, including but not limited to acellular network (e.g., Global System for Mobile Communications (GSM),Long-Term Evolution (LTE), etc.), a telephony network, a digitalsubscriber line (DSL) network, a cable network, a local area network(LAN), a wide area network (WAN), a wireless local area network (WLAN),a wireless personal area network (WPAN), a global network (e.g., theInternet), or any combination thereof. It should be appreciated that, insuch embodiments, the telecommunications network 104 may serve as acentralized network and, in some embodiments, may be communicativelycoupled to another network (e.g., the Internet). Accordingly, thetelecommunications network 104 may include a variety of other virtualand/or physical network computing devices (e.g., gateways, accesspoints, routers, switches, network hubs, servers, storage devices,compute devices, etc.), as needed to facilitate communication betweenthe endpoint computing device 102 and the network computing device 106,which are not shown to preserve clarity of the description.

The cloud network 108 may be embodied as any type of wired or wirelesscommunication network within or that otherwise enables a cloud computinginfrastructure (i.e., a cloud based network or a cloud enabled network).Similar to the telecommunications network 104, it should be appreciatedthat, the cloud network 108 may serve as a centralized network and, insome embodiments, may be communicatively coupled to another network(e.g., the Internet). Accordingly, the cloud network 108 may include avariety of other virtual and/or physical network computing devices(e.g., gateways, access points, routers, switches, network hubs,servers, storage devices, compute devices, etc.), as needed tofacilitate communication between the network computing device 106 andthe cloud compute/storage device 110, which are not shown to preserveclarity of the description.

Referring now to FIG. 3, in use, the network computing device 106establishes an environment 300 during operation. The illustrativeenvironment 300 includes a network traffic ingress/egress manager 308and an application layer packet translator 310. The various componentsof the environment 300 may be embodied as hardware, firmware, software,or a combination thereof. As such, in some embodiments, one or more ofthe components of the environment 300 may be embodied as circuitry orcollection of electrical devices (e.g., network traffic ingress/egressmanagement circuitry 308, application layer packet translation circuitry310, etc.).

It should be appreciated that, while not illustratively shown, at leasta portion of the network traffic ingress/egress management circuitry 308and the application layer packet translation circuitry 310 may form aportion of the communication circuitry 210, or more particularly of theNIC 212. However, it should be appreciated that, in other embodiments,one or more functions of the network traffic ingress/egress managementcircuitry 308 and the application layer packet translation circuitry 310as described herein may form a portion of one or more of the computeengine 200, the I/O subsystem 206, the communication circuitry 210,and/or other components of the network computing device 106. Further, insome embodiments, one or more of the components of the environment 300may be embodied as virtualized hardware components or emulatedarchitecture, which may be established and maintained by the computeengine 200, the communication circuitry 210, and/or other components ofthe network computing device 106. It should be appreciated that thenetwork computing device 106 may include other components,sub-components, modules, sub-modules, logic, sub-logic, and/or devicescommonly found in a computing device, which are not illustrated in FIG.3 for clarity of the description.

In the illustrative environment 300, the network computing device 106additionally includes policy data 302, network function data 304, andnetwork packet data 306, each of which may be accessed by the variouscomponents and/or sub-components of the network computing device 106.Further, each of the policy data 302, the network function data 304, andthe network packet data 306 may be accessed by the various components ofthe network computing device 106. Additionally, it should be appreciatedthat in some embodiments the data stored in, or otherwise representedby, each of the policy data 302, the network function data 304, and thenetwork packet data 306 may not be mutually exclusive relative to eachother. For example, in some implementations, data stored in the policydata 302 may also be stored as a portion of one or more of the networkfunction data 304 and/or the network packet data 306, or vice versa. Assuch, although the various data utilized by the network computing device106 is described herein as particular discrete data, such data may becombined, aggregated, and/or otherwise form portions of a single ormultiple data sets, including duplicative copies, in other embodiments.

The network traffic ingress/egress manager 308, which may be embodied ashardware, firmware, software, virtualized hardware, emulatedarchitecture, and/or a combination thereof as discussed above, isconfigured to receive inbound and route/transmit outbound networktraffic. To do so, the illustrative network traffic ingress/egressmanager 308 is configured to facilitate inbound network communications(e.g., network traffic, network packets, network flows, etc.) to thenetwork computing device 106. Accordingly, the network trafficingress/egress manager 308 is configured to manage (e.g., create,modify, delete, etc.) connections to physical and virtual network ports(i.e., virtual network interfaces) of the network computing device 106(e.g., via the communication circuitry 210), as well as the ingressbuffers/queues associated therewith. Additionally, the network trafficingress/egress manager 308 is configured to facilitate outbound networkcommunications (e.g., network traffic, network packet streams, networkflows, etc.) from the network computing device 106. To do so, thenetwork traffic ingress/egress manager 308 is configured to manage(e.g., create, modify, delete, etc.) connections to physical and virtualnetwork ports/interfaces of the network computing device 106 (e.g., viathe communication circuitry 210), as well as the egress buffers/queuesassociated therewith.

The application layer packet translator 310, which may be embodied ashardware, firmware, software, virtualized hardware, emulatedarchitecture, and/or a combination thereof as discussed above, isconfigured to translate received network packets, at the applicationlayer, between an API-based, cloud-ready collection of VNF services anda packet-switched network (e.g., the telecommunications network 104 orthe cloud network 108 of FIG. 1) from which services of a VNF vendororiginate. In some embodiments, the application layer packet translator310 may be embodied as a network function operating as a proxy of a VNFservices network (see, e.g., the VNF services network 606 of FIG. 6) ofmicroservices as presented to a telecommunications network (e.g., thetelecommunications network 104 of FIG. 1). It should be appreciatedthat, in other embodiments the VNF services network may be comprised ofone or more functions (i.e., functions-as-a-service (FaaS)) as opposedto microservices.

In other embodiments, the application layer packet translator 310 may beembodied as a network function operating as a proxy of atelecommunications network (e.g., the telecommunications network 104 ofFIG. 1) as presented to a VNF services network (see, e.g., the VNFservices network 606 of FIG. 6) of microservices. In other words, indeployment, the application layer packet translator 310 will beconnected to both sides of the telecommunications network, and usescalable microservices (e.g., running in the cloud network 108 ofFIG. 1) to perform network functions. Accordingly, theencapsulation/decapsulation functions as described herein allows variousVNF instances that are called in the appropriate order (i.e., the packetflow becomes a call-chain flow).

To translate the received network packets, the illustrative applicationlayer packet translator 310 includes a network packet classifier 312, aservice policy identifier 314, a network function determiner 316, apacket data encapsulator 318, an RPC API invoker 320, and an RPCresponse call translator 322. It should be appreciated that each of thenetwork packet classifier 312, the service policy identifier 314, thenetwork function determiner 316, the packet data encapsulator 318, theRPC API invoker 320, and the RPC response call translator 322 of theillustrative application layer packet translator 310 may be separatelyembodied as hardware, firmware, software, virtualized hardware, emulatedarchitecture, and/or a combination thereof.

The network packet classifier 312 is configured to read and classify thereceived network packets. To do so, the network packet classifier 312 isconfigured to read (e.g., using Intel® Data Plane Development Kit(DPDK), various hardware offload capabilities of the NIC 212, etc.) atleast a portion of the header and/or payload of the network packet,identify a flow based on the read portion, and classify the networkpacket as a function of the identified flow. The service policyidentifier 314 is configured to identify a service policy associatedwith the flow classification (e.g., as determined by the network packetclassifier 312) that is usable to identify which VNF instances are to beinvoked for the received packet. To do so, the service policy identifier314 may be configured to perform a lookup operation in a flow databaseas a function of the flow classifier. It should be appreciated that, insome embodiments, the service policy may be a dynamic policy, such thatthe service policy can be changed from time to time, depending oninstruction received from an administrator, available resources, adetected condition, etc. The service policy may be stored in the policydata 302, in some embodiments.

The network function determiner 316 is configured to determine whichVNF(s) are to be invoked for the received packet based on a previouslyidentified service policy (e.g., as identified by the service policyidentifier 314), as well as a corresponding location of each VNF. Asdescribed previously, each VNF has a corresponding URI which is usableto make RPC calls. Accordingly, the network function determiner 316 isconfigured to determine which URI(s) correspond to the determinedVNF(s). The packet data encapsulator 318 is configured to encapsulate atleast a portion of the received network packets at the application layer(i.e., layer seven of the Open System Interconnection (OSI) model). Todo so, the packet data encapsulator 318 is configured to encapsulate atleast a portion of the received network packets as one or moreparameters of an RPC.

The RPC API invoker 320 is configured to invoke the determined VNFinstances directly through an API call (e.g., a representational statetransfer (REST) API), based a corresponding RPC. Accordingly, the RPCAPI invoker 320 can implement service chaining with network functioncalls in an imperative way. In other words, some component (e.g., thenetwork traffic ingress/egress manager 308) receives network packets(e.g., via a network interface of the NIC 212 of FIG. 2) and the RPC APIinvoker 320 is configured to make a call or a sequence of calls to theVNF(s), such as may be determined by the network function determiner316. The RPC response call translator 322 is configured to translateresponses received from the VNF(s) into network packet trains that areappropriate for transmission to a target computing device (e.g., theendpoint computing device from which the network packet was received,another network computing device 106, a cloud compute/storage device110, etc.).

Referring now to FIGS. 4A and 4B, a method 400 for processing a networkpacket between telecommunication and cloud networks (e.g., between thetelecom network 104 and the cloud network 108 of FIG. 1) is shown whichmay be executed by a network computing device (e.g., the networkcomputing device 106 of FIGS. 1-3), or more particularly by anapplication layer packet translator of the network computing device 106(e.g., the application layer packet translator 310 of FIG. 3). Themethod 400 begins with block 402, in which the application layer packettranslator 310 determines whether a network packet has been received(e.g., from the endpoint computing device 102 of FIG. 1). If so, themethod 400 advances to block 404.

In block 404, the application layer packet translator 310 retrievesidentifying information from the received network packet. Theidentifying information may include any type of data usable to identifya flow of the network packet, such as source identifying information(e.g., an Internet Protocol (IP) address, a port number, a media accesscontrol (MAC) address, etc., of the computing device from which thenetwork packet was received), target identifying information (e.g., anIP address, a port number, a MAC address, etc., of the computing devicefor which the network packet is to be transmitted), payload data typeidentifying information (e.g., data, voice, text, video, audio, etc.),workload type (e.g., streaming, file transfer, data backup, etc.), etc.

In block 406, the application layer packet translator 310 determines aservice policy as a function of the identifying information (e.g., as afunction of the identified flow corresponding to the received networkpacket). The service policy includes any type of information usable toidentify one or more VNF instances which are to be invoked (e.g.,serially, in parallel, etc.) to perform some level of processing on thereceived network packet. As described previously, each of the VNFinstances perform some type of processing service on the network packet,including firewall services, NAT services, load-balancing services, DPIservices, TCP optimization services, etc.

In block 408, the application layer packet translator 310 identifies oneor more VNF instances to process at least a portion of the receivednetwork packet based on the VNF instance(s) as required under thedetermined service policy. As described previously, the service policymay be dynamic (i.e., change at any given time based on certainconditions, requirements, etc.). Accordingly, it should be appreciatedthat different network packets of the same flow, or same flow type, mayrequire different VNF instance(s). In block 410, the application layerpacket translator 310 may identify a context associated with theidentified VNF instance(s).

In block 412, the application layer packet translator 310 maps thereceived network packet to the identified VNF instance(s). For example,in some embodiments, the application layer packet translator 310 may mapthe network packet to the identified VNF instance(s) in a forwardingtable (i.e., an application layer-level forwarding table). As alsodescribed previously, each VNF instance has a corresponding URI to makeRPCs. Accordingly, as shown in block 414, the application layer packettranslator 310 may map the received network packet to each correspondingURI of each identified VNF instance. Additionally, in some embodiments,in block 416, the application layer packet translator 310 may map thereceived network packet to a context and/or configuration correspondingto each identified VNF instance. For example, in some embodiments, a VNFinstance may be the same for different service chains, but each servicechain may have a different configuration of the VNF instance.Accordingly, in such embodiments, the context/configuration of a VNFinstance may be passed to the VNF instance. As such, memory can besaved, as a single VNF instance can essentially be reconfigured andreused, rather than creating multiple VNF instances to perform generallythe same function.

In block 418, the application layer packet translator 310 encapsulatesat least a portion of the data of the received network packet (e.g., atleast a portion of the header and/or payload of the network packet) asone or more parameters of one or more RPCs. In some embodiments, inblock 420, the application layer packet translator 310 may encapsulateat least a portion of the data of the received network packet asparameter(s) of a sequence of RPCs (i.e., a service chain of VNFinstances). Additionally, in some embodiments, in block 422, theapplication layer packet translator 310 may encapsulate the identifiedcontext of the VNF instance as another parameter of the RPC to that VNFinstance.

In block 424, as shown in FIG. 4B, the application layer packettranslator 310 invokes the one or more identified VNF instances with theRPC parameters using corresponding API calls. In block 426, theapplication layer packet translator 310 determines whether an RPCcallback has been received indicating that the processing by the one ormore VNF instances has completed. As described previously, inalternative embodiments, the RPC may return processed data of theprocessed network packet (i.e., as opposed to the RPC callback). If theRPC callback has been received, the method 400 advances to block 428, inwhich the application layer packet translator 310 maps the RPC responsedata received with the RPC callback to data of the received networkpacket.

In block 430, the application layer packet translator 310 creates a newnetwork packet. Additionally, in block 432, the application layer packettranslator 310 includes information in the header of the new networkpacket based on the mapped RPC response data. It should be appreciatedthat, in some embodiments, as a function of the RPC response received,the application layer packet translator 310 may perform another action,such as dropping the packet, notifying the sender of the result, etc. Inblock 434, the application layer packet translator 310 transmits the newpacket to a target computing device (e.g., the endpoint computing devicefrom which the network packet was received, another network computingdevice 106, a cloud compute/storage device 110, etc.). It should beappreciated that the target computing device may be determined as afunction of the location of the target computing device relative to thenetwork computing device 106 (e.g., same geographical location, samedata center, etc.).

In some embodiments, a single application layer packet translator 310may be used to perform the invocation and receive the callback (i.e.,the entirety of the method 400); whereas in other embodiments, twoapplication layer packet translators 310 may be used (see, e.g., theenvironment 500 of FIG. 5). In such two application layer packettranslator 310 embodiments, one application layer packet translator 310may receive the network packet and perform the invocation (i.e., blocks402-418 of the method 400), while another application layer packettranslator 310 receives the RPC callback and creates/transmits a networkpacket in response to having received the RPC callback (i.e., blocks420-428 of the method 400).

Referring now to FIG. 5, an environment 500 illustrates running VNFinstances implemented as microservices on the network computing device106. As described previously, as illustratively shown as microservices,each VNF instance may be implemented as a function (e.g., afunction-as-a-service (FaaS)), in other embodiments. The illustrativeenvironment 500 includes a first application layer packet translator310, designated as application layer packet translator 310 a, which iscommunicatively coupled to a telecommunications network interface, and asecond application layer packet translator 310, designated asapplication layer packet translator 310 b, which is communicativelycoupled to a cloud network interface 516. It should be appreciated that,while illustratively shown as residing on the same network computingdevice 106 (e.g., to minimize inter-network computing device 106communications and, therefore, realizing efficiency and performancebenefits), one or more of the microservices 506 and/or the applicationlayer packet translators 310 a, 310 b may reside on another networkcomputing device 106. The one or more microservices are illustrativeshown as a first set of microservices 506 designated as microservices(1) 506 a, a second set of microservices 506 designated as microservices(2) 506 b, and a third set of microservices 506 designated asmicroservices (N) 506 c (e.g., in which “N” represents the Nth set ofmicroservices 506 and N is a positive integer).

The illustrative environment 500 additionally includes a resourcemanager 508, a service orchestrator 510, and a container manager 512.The resource manager 508 is configured to monitor and allocate resourcesof the VNF instances. It should be appreciated that, since each VNF isself-contained, the VNF instances can be run on different cores almostindependently. The service orchestrator 510 is configured to orchestratethe VNF services (e.g., the VNF service 504), such that the serviceorchestrator 510 can hide details of the network connection, while theVNF instances maintain a simpler RPC interface. To do so, the APIssupported by the VNF instances can be extended with a method to createservice flows (i.e., instructions to make a call to a subsequent VNFinstead of responding to the request with modified network packet data).

Further, as a result of the application layer encapsulation, the VNFinstances can be implemented as microservices, or a sequence ofmicroservices (e.g., the sequence of microservices 506), on an existinginfrastructure, such as Kubernetes, including existing public cloudinfrastructures. However, it should be appreciated that an efficientimplementation may require a specific software stack to be used. Asillustratively shown, an optimized RPC stack 514, such as a vectorpacket processor (VPP), depending on the embodiment, may be used in therole of a virtual switch (vSwitch). Further, a TCP stack feature may beemployed by the TCP protocol, which can replace connections betweenprocesses on the same host with a dedicated shared memory buffer, suchas may be configured when a connection is established. The containermanager 512 is configured to setup and manage the VNF services 504 inembodiments in which the VNF services 504 are being run in containers.It should be appreciated that, while a dedicated virtual NIC (vNIC) maybe required for each connection in implementations in which virtualmachines (VMs) are used, as opposed to containers.

In use, the application layer packet translator 310 a receives incomingnetwork packets (e.g., via the telecom network interface 502) from asource computing device (e.g., the endpoint computing device 102 of FIG.1). It should be appreciated that the application layer packettranslator 310 a is configured to receive the network packets using linerate efficient mechanisms, such as DPDK or PF_RING™. The applicationlayer packet translator 310 a identifies the VNF service flow inaccordance with the corresponding service policy, which as describedpreviously can associate specific network packets to a sequence offunction calls (e.g., similar to the function of a classifier in servicefunction chains (SFCs)).

Additionally, the service policy may provide configuration and contextinformation as well. Accordingly, in such embodiments in which theconfiguration and context can be passed to the VNF instances along withthe network packet data, the same VNF can be used in different VNFservice chains with different configurations. Depending on theembodiment, the context and configuration may be passed to the VNFinstance directly, for example, in an embodiment in which the servicechain serves a single tenant and the size of the context andconfiguration does not consume much overhead such that inefficienciesmay be realized. In other embodiments, the VNF may be passed anidentifier (e.g., a key), which identifies a database or other data fromwhich the context and configuration (e.g., based on the service chain)can be extracted. It should be appreciated that such databases can beimplemented as high-performance in-memory distributed databases with lowlatency access using framework provided APIs.

Unlike present technologies the application layer packet translator 310a is configured to invoke the one or more VNF instances of theidentified VNF service with the data of the received network packetencapsulated as RPC parameters of API calls, such that the servicechaining with network function calls can be implemented in an imperativeway (e.g., via a sequence of calls to network functions or microservicesthereof). As such, switching overhead can be replaced by function calls.It should be appreciated that the VNF instances can be extended withconfiguration and context, such that the same function can be used indifferent service chains with different configurations. In someembodiments, the application layer packet translator 310 may maintain aflow database which defines a packet matching rule with the associatedURI for each RPC.

Upon completion of the network packet processing across the microservicechain of the VNF, the RPC output is received at the application layerpacket translator 310 b from translation from the RPC response to one ormore network packets formatted for transmission (e.g., via the cloudnetwork interface 516) to a target computing device (e.g., the cloudcompute/storage device 110 of FIG. 1), such as by using use DPDK and/orone or more hardware offload features. To do so, the application layerpacket translator 310 b is configured to create the one or more networkpackets for transmission and adds specific headers and/or data to thecreated network packets consistent with the results received from theVNF service(s).

In some embodiments, the VNF instances may be deployed using afunction-as-a-service (FaaS) approach (i.e., when a network function isonly activated for a period of time), or more particularly a networkfunction as a service approach. In such embodiments, it should beappreciated that the VNF instances are implemented in a compiledlanguage to achieve high performance, and each VNF instance can becompiled with the use of the supporting functions/run-time as a sharedobject or plugin. Accordingly, various techniques can be used assecurity precautions, including security by trust (e.g., use signedmodules, a security manifest, etc.), hardware isolation methods (e.g.,stack pivoting, page protection, secure enclaves, etc.), and/orsystem-level isolation (e.g., the loading of functions in a separatenamespace, a dedicated container or VM, etc.).

In some embodiments, VNF instances in shared objects can be wrappedusing a secure RPC mechanism (e.g., gRPC) and executed as separate,isolated processes (i.e., executing as a temporal microservice, existingonly for the lifetime of the VNF instance). Alternatively, if the VNFinstances are provided as source code (e.g., open source, sharedsource), compiler and static verifiers can be used to ensure only theallowed functionality is accessible. Irrespective of the VNFimplementation, VNF instances deployed using the FaaS approach can allowfor the avoidance of data transfer completely (i.e., by transformingnetwork packet data in place, in a “run to completion” model), not justswitching overhead.

Referring now to FIG. 6, an illustrative system 600 for network packetprocessing between an L2+ network 602 (i.e., a layer 2/data link layer,a layer 3/network layer, etc.) and a VNF services network 606, or cloud,of scalable microservices 608 (i.e., a collection of API-based,cloud-ready VNF services) running therein to perform auto-scalable andelastic VNF service deployment in clouds that achieves line ratesrequired in latency sensitive architectures. It should be appreciatedthat the L2+ network 602 may be embodied as any packet switching networkthat needs to consume services (e.g., the telecommunications network 104of FIG. 1). The system 600 includes one or more switches 604 (e.g.,spine or leaf switch(es)) communicatively coupled to the networkcomputing device 106 on which multiple application layer packettranslators 310 reside.

The illustrative application layer packet translators 310 include afirst application layer packet translator 310 designated as applicationlayer packet translator (1) 310 c, a second application layer packettranslator 310 designated as application layer packet translator (2) 310d, and a third application layer packet translator 310 designated asapplication layer packet translator (N) 310 e (N) (e.g., in which “N”represents the Nth application layer packet translator 310 and N is apositive integer). While the application layer packet translators 310are illustratively shown as residing on the same network computingdevice 106, it should be appreciated that one or more of the applicationlayer packet translators 310 may be distributed across multiple networkcomputing devices 106 in other embodiments.

Examples

Illustrative examples of the technologies disclosed herein are providedbelow. An embodiment of the technologies may include any one or more,and any combination of, the examples described below.

Example 1 includes a network computing device for network packetprocessing between cloud and telecommunications networks, the networkcomputing device comprising a compute engine; and communicationcircuitry to receive, by a first application layer packet translator ofthe communication circuitry, a network packet from a source computingdevice via a first network; identify, by the first application layerpacket translator, a virtual network function (VNF) instance based onthe received network packet; perform, by the first application layerpacket translator, an application layer encapsulation of at least aportion of data of the received network packet as a parameter of aremote procedure call (RPC) associated with the VNF instance; invoke, bythe first application layer packet translator, the identified VNFinstance using an API call corresponding to the RPC that includes theRPC parameter; receive, by the invoked VNF instance, an RPC callresponse to a second application layer packet translator, wherein theRPC call response indicates the invoked VNF instance has processed atleast a portion of the encapsulated data; generate, by the secondapplication layer packet translator and subsequent to having receivedthe RPC call response, a new network packet as a function of the RPCcall response; and transmit, by the second application layer packettranslator, the new network packet to a target computing device via asecond network.

Example 2 includes the subject matter of Example 1, and wherein toidentify the VNF instance based on the received network packet comprisesto (i) determine a flow of the network packet, (ii) compare thedetermined flow against a known flow of a service policy to determine amatching flow, and (iii) identify the VNF instance as a function of aVNF identifier associated with the matching flow.

Example 3 includes the subject matter of any of Examples 1 and 2, andwherein the VNF identifier comprises a uniform resource identifier (URI)and wherein to invoke the identified VNF instance using the API callcomprises to invoke the identified VNF instance as a function of theURI.

Example 4 includes the subject matter of any of Examples 1-3, andwherein to perform the application layer encapsulation of at least aportion of data of the received network packet as the parameter of theRPC call comprises to perform the application layer encapsulation of atleast a portion of data of the received network packet as a parameterfor each of a sequence of a plurality of RPCs.

Example 5 includes the subject matter of any of Examples 1-4, andwherein to identify the VNF instance comprises to identify a VNF servicethat includes a plurality of microservices or a plurality of functions.

Example 6 includes the subject matter of any of Examples 1-5, andwherein the RPC call response indicates the invoked VNF instance hasprocessed at least a portion of the encapsulated data via the pluralityof microservices or the plurality of functions of the VNF service.

Example 7 includes the subject matter of any of Examples 1-6, andwherein to generate the new network packet as a function of the RPC callresponse comprises to include data associated with the RPC call responseto at least one of a header and a payload of the new network packet.

Example 8 includes the subject matter of any of Examples 1-7, andwherein the first network comprises a telecommunications network and thesecond network comprises a cloud network.

Example 9 includes the subject matter of any of Examples 1-8, andwherein the communication circuitry is further to identify, by the firstapplication layer packet translator, a context for the VNF instancebased on at least a portion of the received network packet, and whereinto perform the application layer encapsulation of the at least a portionof data of the received network packet as the parameter of the RPCassociated with the VNF instance includes to perform the applicationlayer encapsulation of the context for the VNF instance as anotherparameter of the RPC call.

Example 10 includes one or more machine-readable storage mediacomprising a plurality of instructions stored thereon that, in responseto being executed, cause a network computing device to receive, by afirst application layer packet translator of the network computingdevice, a network packet from a source computing device via a firstnetwork; identify, by the first application layer packet translator, avirtual network function (VNF) instance based on the received networkpacket; perform, by the first application layer packet translator, anapplication layer encapsulation of at least a portion of data of thereceived network packet as a parameter of a remote procedure call (RPC)associated with the VNF instance; invoke, by the first application layerpacket translator, the identified VNF instance using an API callcorresponding to the RPC that includes the RPC parameter; receive, bythe invoked VNF instance, an RPC call response to a second applicationlayer packet translator, wherein the RPC call response indicates theinvoked VNF instance has processed at least a portion of theencapsulated data; generate, by the second application layer packettranslator and subsequent to having received the RPC call response, anew network packet as a function of the RPC call response; and transmit,by the second application layer packet translator, the new networkpacket to a target computing device via a second network.

Example 11 includes the subject matter of Example 10, and wherein toidentify the VNF instance based on the received network packet comprisesto (i) determine a flow of the network packet, (ii) compare thedetermined flow against a known flow of a service policy to determine amatching flow, and (iii) identify the VNF instance as a function of aVNF identifier associated with the matching flow.

Example 12 includes the subject matter of any of Examples 10 and 11, andwherein the VNF identifier comprises a uniform resource identifier (URI)and wherein to invoke the identified VNF instance using the API callcomprises to invoke the identified VNF instance as a function of theURI.

Example 13 includes the subject matter of any of Examples 10-12, andwherein to perform the application layer encapsulation of at least aportion of data of the received network packet as the parameter of theRPC call comprises to perform the application layer encapsulation of atleast a portion of data of the received network packet as a parameterfor each of a sequence of a plurality of RPCs.

Example 14 includes the subject matter of any of Examples 10-13, andwherein to identify the VNF instance comprises to identify a VNF servicethat includes a plurality of microservices or a plurality of functions.

Example 15 includes the subject matter of any of Examples 10-14, andwherein the RPC call response indicates the invoked VNF instance hasprocessed at least a portion of the encapsulated data via the pluralityof microservices or the plurality of functions of the VNF service.

Example 16 includes the subject matter of any of Examples 10-15, andwherein to generate the new network packet as a function of the RPC callresponse comprises to include data associated with the RPC call responseto at least one of a header and a payload of the new network packet.

Example 17 includes the subject matter of any of Examples 10-16, andwherein the first network comprises a telecommunications network and thesecond network comprises a cloud network.

Example 18 includes the subject matter of any of Examples 10-17, andwherein the plurality of instructions further cause the networkcomputing device to identify, by the first application layer packettranslator, a context for the VNF instance based on at least a portionof the received network packet, and wherein to perform the applicationlayer encapsulation of the at least a portion of data of the receivednetwork packet as the parameter of the RPC associated with the VNFinstance includes to perform the application layer encapsulation of thecontext for the VNF instance as another parameter of the RPC call.

Example 19 includes a network computing device for network packetprocessing between cloud and telecommunications networks, the networkcomputing device comprising means for receiving, by a first applicationlayer packet translator of the network computing device, a networkpacket from a source computing device via a first network; means foridentifying, by the first application layer packet translator, a virtualnetwork function (VNF) instance based on the received network packet;means for performing, by the first application layer packet translator,an application layer encapsulation of at least a portion of data of thereceived network packet as a parameter of a remote procedure call (RPC)associated with the VNF instance; means for invoking, by the firstapplication layer packet translator, the identified VNF instance usingan API call corresponding to the RPC that includes the RPC parameter;means for receiving, by the invoked VNF instance, an RPC call responseto a second application layer packet translator, wherein the RPC callresponse indicates the invoked VNF instance has processed at least aportion of the encapsulated data; means for generating, by the secondapplication layer packet translator and subsequent to having receivedthe RPC call response, a new network packet as a function of the RPCcall response; and circuitry for transmitting, by the second applicationlayer packet translator, the new network packet to a target computingdevice via a second network.

Example 20 includes the subject matter of Example 19, and wherein themeans for identifying the VNF instance based on the received networkpacket comprises means for (i) determining a flow of the network packet,(ii) comparing the determined flow against a known flow of a servicepolicy to determine a matching flow, and (iii) identifying the VNFinstance as a function of a VNF identifier associated with the matchingflow.

Example 21 includes the subject matter of any of Examples 19 and 20, andwherein the VNF identifier comprises a uniform resource identifier (URI)and wherein the means for invoking the identified VNF instance using theAPI call comprises means for invoking the identified VNF instance as afunction of the URI.

Example 22 includes the subject matter of any of Examples 19-21, andwherein the means for performing the application layer encapsulation ofat least a portion of data of the received network packet as theparameter of the RPC call comprises means for performing the applicationlayer encapsulation of at least a portion of data of the receivednetwork packet as a parameter for each of a sequence of a plurality ofRPCs.

Example 23 includes the subject matter of any of Examples 19-22, andwherein the means for identifying the VNF instance comprises means foridentifying a VNF service that includes a plurality of microservices ora plurality of functions.

Example 24 includes the subject matter of any of Examples 19-23, andwherein the means for generating the new network packet as a function ofthe RPC call response comprises means for including data associated withthe RPC call response to at least one of a header and a payload of thenew network packet.

Example 25 includes the subject matter of any of Examples 19-24, andfurther including means for identifying, by the first application layerpacket translator, a context for the VNF instance based on at least aportion of the received network packet, and wherein the means forperforming the application layer encapsulation of the at least a portionof data of the received network packet as the parameter of the RPCassociated with the VNF instance includes means for performing theapplication layer encapsulation of the context for the VNF instance asanother parameter of the RPC call.

1-20. (canceled)
 21. Network apparatus to be communicatively coupled toat least one computing device, the network apparatus also to becommunicatively coupled, via at least one cloud network, to at least onecloud service provider, the network apparatus comprising: applicationprogramming interface (API) gateway circuitry configurable to (1) mapreceived network packet data to at least one corresponding service ofthe at least one cloud service provider and (2) generate request datafor use in requesting providing of the at least one correspondingservice, the received network packet data being received from the atleast one computing device by the network apparatus, the at least onecorresponding service to be provided in response, at least in part, tothe request data, the providing of the at least one correspondingservice to result in generation of response data to be provided to theat least one computing device via the at least one cloud network and thenetwork apparatus; and communication interface circuitry to: receive thenetwork packet data; transmit the request data to the at least one cloudservice provider via the at least one cloud network; and transmit theresponse data to the at least one computing device; wherein: a pluralityof services are comprised, at least in part, in the at least one cloudservice provider; the plurality of services comprise the at least onecorresponding service; the plurality of services are configurable toinclude at least one firewall service; the plurality of servicescorrespond, at least in part, to API calls for use, at least in part, inassociation with the API gateway circuitry; the request data is for usein requesting calling of the at least one corresponding service; the APIgateway circuitry is configurable to: provide application layer-relatedproxy services related to the plurality of services; select, based atleast in part upon the network packet data, the at least onecorresponding service from among the plurality of services; andimplement, at least in part, one or more of the plurality of services.22. The network apparatus of claim 21, wherein: the plurality ofservices comprise virtualized services; and the network apparatus, theAPI gateway circuitry, and/or the at least one cloud service providercomprise one or more distributed computing systems.
 23. The networkapparatus of claim 22, wherein: the API gateway circuitry isconfigurable for use in association with one or more of the following:at least one firewall service; at least one load-balancing service; andat least one deep packet inspection service.
 24. The network apparatusof claim 23, wherein: the providing of the at least one correspondingservice is associated with at least one uniform resource identifier. 25.The network apparatus of claim 23, wherein: the request data is to begenerated based at least in part upon policy data of the API gatewaycircuitry.
 26. The network apparatus of claim 23, wherein: the networkapparatus is to forward the request data based at least in part uponforwarding data that corresponds to mapping of the received networkpacket data to at least one corresponding service; and the plurality ofservices comprise one or more microservices.
 27. The network apparatusof claim 23, wherein: the at least one corresponding service is to beprovided, at least in part, via at least one internet network, to the atleast one computing device; and the virtualized services are to beimplemented via one or more virtual machines and/or one or morecontainers.
 28. One or more machine-readable storage media storinginstructions for being executed by circuitry, the circuitry to becommunicatively coupled to at least one computing device, the circuitryalso to be communicatively coupled, via at least one cloud network, toat least one cloud service provider, the instructions when executed bythe circuitry resulting in the circuitry being configurable to performoperations comprising: mapping received network packet data to at leastone corresponding service of the at least one cloud service provider;and generating request data for use in requesting providing of the atleast one corresponding service, the received network packet data to bereceived from the at least one computing device, the at least onecorresponding service to be provided in response, at least in part, tothe request data, the providing of the at least one correspondingservice to result in generation of response data to be provided to theat least one computing device via the at least one cloud network;wherein: a plurality of services are comprised, at least in part, in theat least one cloud service provider; the plurality of services comprisethe at least one corresponding service; the plurality of services areconfigurable to include at least one firewall service; the plurality ofservices correspond, at least in part, to application programminginterface (API) calls for use, at least in part, in association with thecircuitry; the request data is for use in requesting calling of the atleast one corresponding service; and the circuitry is configurable to:provide application layer-related proxy services related to theplurality of services; select, based at least in part upon the networkpacket data, the at least one corresponding service from among theplurality of services; and implement, at least in part, one or more ofthe plurality of services.
 29. The one or more machine-readable storagemedia of claim 28, wherein: the instructions, when executed by thecircuitry, result in the circuitry being configured to comprise: APIgateway circuitry to perform: the mapping of the received network packetdata to the at least one corresponding service of the at least one cloudservice provider; and the generating of the request data for use in therequesting of the providing of the at least one corresponding service;and communication interface circuitry to: receive the network packetdata; transmit the request data to the at least one cloud serviceprovider via the at least one cloud network; and transmit the responsedata to the at least one computing device.
 30. The one or moremachine-readable storage media of claim 28, wherein: the plurality ofservices comprise virtualized services; and the circuitry and/or the atleast one cloud service provider comprise one or more distributedcomputing systems.
 31. The one or more machine-readable storage media ofclaim 30, wherein: the circuitry is configurable for use in associationwith one or more of the following: at least one firewall service; atleast one load-balancing service; and at least one deep packetinspection service.
 32. The one or more machine-readable storage mediaof claim 31, wherein: the providing of the at least one correspondingservice is associated with at least one uniform resource identifier. 33.The one or more machine-readable storage media of claim 31, wherein: therequest data is to be generated based at least in part upon policy dataof the circuitry.
 34. The one or more machine-readable storage media ofclaim 31, wherein: the request data is to be forwarded based at least inpart upon forwarding data that corresponds to the mapping of thereceived network packet data to at least one corresponding service; andthe plurality of services comprise one or more microservices.
 35. Theone or more machine-readable storage media of claim 31, wherein: the atleast one corresponding service is to be provided, at least in part, viaat least one internet network, to the at least one computing device; andthe virtualized services are to be implemented via one or more virtualmachines and/or one or more containers.
 36. A method implemented usingcircuitry, the circuitry to be communicatively coupled to at least onecomputing device, the circuitry also to be communicatively coupled, viaat least one cloud network, to at least one cloud service provider, themethod comprising: mapping, by the circuitry, received network packetdata to at least one corresponding service of the at least one cloudservice provider; and generating, by the circuitry, request data for usein requesting providing of the at least one corresponding service, thereceived network packet data to be received from the at least onecomputing device, the at least one corresponding service to be providedin response, at least in part, to the request data, the providing of theat least one corresponding service to result in generation of responsedata to be provided to the at least one computing device via the atleast one cloud network; wherein: a plurality of services are comprised,at least in part, in the at least one cloud service provider; theplurality of services comprise the at least one corresponding service;the plurality of services are configurable to include at least onefirewall service; the plurality of services correspond, at least inpart, to application programming interface (API) calls for use, at leastin part, in association with the circuitry; the request data is for usein requesting calling of the at least one corresponding service; and thecircuitry is configurable to: provide application layer-related proxyservices related to the plurality of services; select, based at least inpart upon the network packet data, the at least one correspondingservice from among the plurality of services; and implement, at least inpart, one or more of the plurality of services.
 37. The method of claim36, wherein: the circuitry comprises: API gateway circuitry to perform:the mapping of the received network packet data to the at least onecorresponding service of the at least one cloud service provider; andthe generating of the request data for use in the requesting of theproviding of the at least one corresponding service; and communicationinterface circuitry to: receive the network packet data; transmit therequest data to the at least one cloud service provider via the at leastone cloud network; and transmit the response data to the at least onecomputing device.
 38. The method of claim 36, wherein: the plurality ofservices comprise virtualized services; and the circuitry and/or the atleast one cloud service provider comprise one or more distributedcomputing systems.
 39. The method of claim 38, wherein: the circuitry isconfigurable for use in association with one or more of the following:at least one firewall service; at least one load-balancing service; andat least one deep packet inspection service.
 40. The method of claim 39,wherein: the providing of the at least one corresponding service isassociated with at least one uniform resource identifier; the requestdata is to be generated based at least in part upon policy data of thecircuitry; the request data is to be forwarded based at least in partupon forwarding data that corresponds to the mapping of the receivednetwork packet data to at least one corresponding service; and theplurality of services comprise one or more microservices.
 41. The methodof claim 39, wherein: the at least one corresponding service is to beprovided, at least in part, via at least one internet network, to the atleast one computing device; and the virtualized services are to beimplemented via one or more virtual machines and/or one or morecontainers.
 42. A computerized system to be communicatively coupled toat least one computing device, the computerized system comprising: atleast one cloud service provider; and network apparatus to becommunicatively coupled, via at least one cloud network, to the at leastone cloud service provider, the network apparatus also to becommunicatively coupled to the at least one computing device, thenetwork apparatus comprising: application programming interface (API)gateway circuitry configurable to (1) map received network packet datato at least one corresponding service of the at least one cloud serviceprovider and (2) generate request data for use in requesting providingof the at least one corresponding service, the received network packetdata being received from the at least one computing device by thenetwork apparatus, the at least one corresponding service to be providedin response, at least in part, to the request data, the providing of theat least one corresponding service to result in generation of responsedata to be provided to the at least one computing device via the atleast one cloud network and the network apparatus; and communicationinterface circuitry to: receive the network packet data; transmit therequest data to the at least one cloud service provider via the at leastone cloud network; and transmit the response data to the at least onecomputing device; wherein: a plurality of services are comprised, atleast in part, in the at least one cloud service provider; the pluralityof services comprise the at least one corresponding service; theplurality of services are configurable to include at least one firewallservice; the plurality of services correspond, at least in part, to APIcalls for use, at least in part, in association with the API gatewaycircuitry; the request data is for use in requesting calling of the atleast one corresponding service; the API gateway circuitry isconfigurable to: provide application layer-related proxy servicesrelated to the plurality of services; select, based at least in partupon the network packet data, the at least one corresponding servicefrom among the plurality of services; and implement, at least in part,one or more of the plurality of services.
 43. The computerized system ofclaim 42, wherein: the plurality of services comprise virtualizedservices; the network apparatus, the API gateway circuitry, and/or theat least one cloud service provider comprise one or more distributedcomputing systems; and the API gateway circuitry is configurable for usein association with one or more of the following: at least one firewallservice; at least one load-balancing service; and at least one deeppacket inspection service.
 44. The computerized system of claim 43,wherein: the providing of the at least one corresponding service isassociated with at least one uniform resource identifier; the requestdata is to be generated based at least in part upon policy data of theAPI gateway circuitry; the network apparatus is to forward the requestdata based at least in part upon forwarding data that corresponds tomapping of the received network packet data to at least onecorresponding service; and the plurality of services comprise one ormore microservices.
 45. The computerized system of claim 43, wherein:the at least one corresponding service is to be provided, at least inpart, via at least one internet network, to the at least one computingdevice; and the virtualized services are to be implemented via one ormore virtual machines and/or one or more containers.